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IEEE 802.15.4 Information Element for the IETF 
Abstract 


TEEE Std 802.15.4 defines Information Elements (IEs) that can be used 
to extend 802.15.4 in an interoperable manner. The IEEE 802.15 
Assigned Numbers Authority (ANA) manages the registry of the 
Information Elements. This document formulates a request for ANA to 
allocate a number from that registry for the IETF and describes how 


the IE is formatted to provide subtypes. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8137. 


Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction 


IEEE Std 802.15.4 [IEEE802.15.4] is a standard, referred to by RFC 
4944 [RFC4944] and other documents, that enables very low-cost and 
low-power communications. The standard defines numerous optional 
Physical Layers (PHYs) operating in many different frequency bands 
with a simple and effective Medium Access Control (MAC). 
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IEEE Std 802.15.4 defines Information Elements (IEs) that can be used 


to extend 802.15.4 in an interoperable manner. An IE provides a 
flexible, extensible, and easily implementable method of 


encapsulating information. The general format of an IE as defined in 


Section 7.4 of IEEE Std 802.15.4-2015 [IEEE802.15.4] consists of an 
identification (ID) field, a length field, and a content field. 


Multiple IEs may be concatenated, and elements with unknown ID values 


in a list of IEs can be skipped since their length is known. IEs 


provide a flexible container for information that allows the addition 


of new IE definitions in future versions of the standard ina 
backwards-compatible manner. 


There are two different IE types, Header IE and Payload IE. A Header 


TE is part of the MAC header; it is never encrypted, but it may be 


and IETF protocols should not have any direct effect on that 
processing. A Payload IE is part of the MAC payload and may be 
encrypted and authenticated. 


IETF protocols will need to insert information in the 802.15.4 
frames; the 802.15.4 standard enables that by including one or more 


authenticated. Most of the Header IE processing is done by the MAC, 


payload IEs in the frame that will contain the information. For this 


purpose, the IETF requests a dedicated Payload IE from the IEEE 
802.15 Assigned Numbers Authority (ANA) [IEEE802.15-ANA]. The 
current 802.15 ANA database can be found at [IEEE802.15-ANA-DB]. 
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The 802.15.4 operations manual [IEEE802.15-OPS] describes how a 
Standards Development Organization (SDO) may request an allocation of 
one IE. To make this request the SDO has to provide (i) the reason 
for the request, (ii) a description of the protocol format that shows 
an appropriate subtype capability, and (iii) an agreement that only 
one IE number will be allocated for use by the SDO. 


This document provides the information needed for the request. 
2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
"MAY", and "OPTIONAL" in this document are to be interpreted as 
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 
appear in all capitals, as shown here. 


3. Working Groups Benefiting from the IETF 802.15.4 IE 


There are several IETF working groups such as 6TiSCH, 6lo, and CoRE 
that could benefit from the IETF IE. The 6TiSCH Working Group has 
already expressed the need for the IE; this allocation is expected to 
satisfy that need. 


4. IETF IE Subtype Format 


The maximum length of the Payload IE content is 2047 octets, and the 
802.15.4 frame contains a list of payload IEs. A single frame can 
have multiple payload IEs, terminated with the payload IE terminator, 
which may then be followed by the payload. 


Since the 802.15.4 standard defines a list of payload IEs along with 
their structures, there is no need for this document to specify the 
internal nesting structure of the IETF IE. The Payload IE format of 
802.15.4 standard contains the Length field. The length of the 
subtype content can be calculated from the 802.15.4 Payload IE Length 
field of the IETF IE. 
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The format of the IETF IE is as follows: 


1 2 3 
On 23.46 8 9 0 Ue 2 3 4: DnE T 28> 9-00 Ve 23k Ds E 7 889. OF 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Subtype ID | | 
-+-+-+-+-+-+-+-+ | 
subtype content ~ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


: +—+ 


Figure 1: IETF IE Subtype Format 


o Subtype ID is the IANA-allocated number specifying the subtype of 
the IETF IE. Value 0 is reserved for future extensibility, i.e., 
in case a longer subtype ID field is needed. 


o Subtype content is the actual content of the Information Element, 
and its length can be calculated from the Length field of the IETF 
IE. 


One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same 
or different subtypes. 


5. Request to Allocate an IETF IE 


Per the IETF’s request, the IEEE 802.15 Working Group has allocated 
an ID (5) for a Payload IE for IETF use. The IETF understands that 
this is the only ID it will be issued. 


6. Security Considerations 


This document creates an IANA registry for IETF IE subtype IDs (see 
Section 7). The security of the protocols using the IEs MUST be 
described in the documents requesting allocations from this registry. 


The IEEE Std 802.15.4 [IEEE802.15.4] contains methods in which 
security of the IE can be enforced when a frame is received, but this 
is only per IE type. Therefore, all IETF IEs will have the same 
security-level requirements regardless of the subtype ID used. This 
can cause issues if different security processing would be needed and 
any of those IEs would need to be processed in the MAC level. Since 
all IETF protocols should operate at a higher level than the MAC 
level, the higher-layer processing for these IEs SHOULD perform 
separate security policy checking based on the IETF IE subtype ID in 
addition to the checks done by the MAC. 


Kivinen & Kinney Informational [Page 4] 


RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017 


7. (IANA Considerations 


The "IEEE Std 802.15.4 IETF IE Subtype IDs" registry has been created 
as follows: 


Value Subtype ID 
0 Reserved 
1-200 Unassigned 


201-255 Experimental Use 


Any change or addition to this registry requires Expert Review 
[RFC5226]. 


Note that there are vendor-specific IEs already defined in IEEE 


802.15.4 (see Appendix A); because of this, there is no need to 
reserve any subtype IDs for the vendor-specific uses. 
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Appendix A. Vendor Specific IE in IEEE 802.15.4 


IEEE 802.15.4 already has several numbers for different Vendor 
Specific IE types. There is one for the Vendor Specific Header IE 
for Header IEs. There is one incorrectly named Vendor Specific 


Nested IE for Payload IEs, and there is another one with exactly the 
same name, but under the MLME Nested IE long format. All of the 
Vendor Specific IEs start with a 3-octet vendor OUI to identify the 
organization. 
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